Multicast and/or broadcast services (MBSs), also known as multimedia broadcast multicast services (MBMSs), provide content data to a plurality of users who desire to receive such service in a communication network. For example, the content data may be movies, games, files, software programs, or TV programs, and is usually provided by one or more content providers.
FIG. 1 illustrates a block diagram of a conventional communication system 100 for providing MBSs. The communication system 100 includes one or more MBS content servers such as MBS content servers 102-1, 102-2, and 102-3, and one or more base stations (BSs) such as base stations 104-1 and 104-2. For example, the MBS content server 102-1 and the base stations 104-1 and 104-2 may be in a network 106, and the MBS content servers 102-2 and 102-3 may be outside the network 106. In addition, the communication system 100 further includes at least one subscriber station (SS) 108 to receive MBSs from the base stations 104-1 and/or 104-2.
Conventionally, the communication system 100 provides MBSs based on a communication standard, such as a digital video broadcasting (DVB) standard or an IEEE 802.16 standard. For example, based on the DVB standard, the base station 104-1 or 104-2 receives MBS content data from one or more of the MBS content servers 102-1,102-2, and 102-3. The base station 104-1 or 104-2 then transmits the received MBS content data to the subscriber station 108. Typically, to prevent unauthorized users from receiving the MBSs, the MBS content data is encrypted in an application layer or based on an Internet Protocol Security (IPSEC) mechanism in a Transmission Control Protocol/Internet Protocol (TCP/IP) layer. However, data transmission between the base station 104-1 or 104-2 and the subscriber station 108 may not be encrypted.
Also for example, based on the IEEE 802.16 standard, the base station 104-1 or 104-2 receives MBS content data from one or more of the MBS content servers 102-1, 102-2, and 102-3. The base station 104-1 or 104-2 may, in order to prevent unauthorized users from receiving the MBSs, encrypt the received MBS content data with an MBS traffic key (MTK), and transmit the encrypted MBS content data to the subscriber station 108. If an MBS does not need encryption protection, the base station 104-1 or 104-2 may not encrypt MBS content data for that MBS.
FIG. 2 illustrates a conventional method 200 to generate an MTK 202 based on the IEEE 802.16 standard. For example, a base station, such as the base station 104-1 or 104-2 (FIG. 1), may obtain a master key, such as an MBS authorization key (MAK) 204, from an MBS content server, such as the MBS content server 102-1, 102-2, or 102-3 (FIG. 1), or a third party server, such as an Authentication Authorization Accounting (AAA) server, while performing authorization with the MBS content server. The base station also generates a random number as an MBS group traffic encryption key (MGTEK) 206. The base station further uses a function, e.g., the Dot16KDF function, to generate the MTK 202. In addition, the base station transmits the MGTEK 206 to a subscriber station such as the subscriber station 108 (FIG. 1) based on, e.g., the Privacy and Key Management version 2 (PKMv2) protocol. Similarly, the subscriber station may obtain the MAK 204 from the MBS content server during authorization, and use the MAK 204 and the MGTEK 206 received from the base station to generate the MTK 202. Accordingly, the base station may use the MTK 202 to encrypt MBS content data, and the subscriber station may use the MTK 202 to decrypt encrypted MBS content data received from the base station, thereby to receive the MBSs. However, security problems may occur based on the conventional method 200. For example, when the conventional method 200 is used, a tricky user may have unauthorized access to encrypted MBS content data, as described below. A tricky user is a user terminal that uses key information that is obtained when the tricky user is an authorized user to decrypt encrypted MBS content data that is received when the tricky user is an unauthorized user.
FIG. 3 illustrates a conventional MBS data transmission process 300, in which security problems may occur. Referring to FIG. 3, an MBS content server 302 transmits MBS content data to a base station 304. The base station 304 encrypts the MBS content data with an MTK and transmits the encrypted MBS content data to authorized users such as subscriber stations 306-1 and 306-2. However, a tricky user 306-3, which is currently an unauthorized user terminal, may also receive the encrypted MBS content data by unauthorized access to the base station 304 (308). The tricky user 306-3 may store the encrypted MBS content data in a buffer. Later, when the tricky user 306-3 joins the MBSs and finishes authorization with the MBS content server 302 (310), the tricky user 306-3 becomes a subscriber and obtains the MTK. The tricky user 306-3 may then use the MTK to decrypt the encrypted MBS content data stored in the buffer that was received before the tricky user 306-3 joined the MBSs.
FIG. 4 illustrates a conventional MBS data transmission process 400, in which security problems may occur. Referring to FIG. 4, an MBS content server 402 transmits MBS content data to a base station 404. The base station 404 encrypts the MBS content data with an MTK and transmits the encrypted MBS content data to authorized users. Because subscriber stations 406-1 and 406-2 and a tricky user 406-3 join the MBSs and perform authorization with the MBS content server 402 (408), they have the MTK to decrypt the encrypted MBS content data received from the base station 404 (410). Later, the tricky user 406-3 leaves the MBSs (412). However, because the tricky user 406-3 has the MTK, the tricky user 406-3 may continue to receive encrypted MBS content data by unauthorized access to the base station 404 and decrypt the encrypted MBS content data to receive the MBSs (414).